@bastianallgeier I get the concerns, let's try to dissect it a little:

• This is only checking view routes. Yes, technically they could also execute code on load but I would say the scenario where code is executed which is harmful when executed by this check vs. any other visit is low. Though not impossible.
• it surely has a performance implication. But only when this check is actually run. Which is only after login. So not on the regular Panel navigation. We could consider whether we want to differentiate between remembered paths which should be checked and maybe blueprint-defined paths (where we might skip the check and if it results in errors, the developer can easily adjust the blueprint). Ideally we would check both, but if this is a concern.
• We should indeed consider some other return values and whether we then consider the route as valid redirect target or not.

We could also skip calling the route for common routes we know will work by this point (e.g. site).

I like @lukasbestle' idea. Maybe we could make sure to always throw a NotFoundException in our error routes and catch that?

The case here is that we want to specifically handle the remembered redirect after the login.

The suggestion would mean we just always redirect to site if a Panel route is not found without an error message. Not just after login.

Forget my comment. We would still need to run the route action for what I suggested. I mix things up in my head here.

Trying to approach this from a different perspective:

Do we even want to silently redirect to the site view on a "page not found" error?

If I'm already logged in and try to visit a page view of a non-existing page, I get a proper view with the error message. From there I can navigate to whatever other view I want, so I'm not lost.

Could we do the same with the redirect after login? So instead of displaying the error in a dialog on the login view, we would perform the redirect to the provided URL and display the k-error-view there as normal.

@lukasbestle good point. The error dialog is definitely weird here. I had that in different scenarios where it really bothered me. So this is something that we should definitely fix - independently from the login redirect issue. If a redirect leads to an error view, the redirect should go through and not lead to the error dialog.

I think the login redirect is special here as running into the error is not like usually intentionally trying a panel route that doesn't exist, but just trying to access a page before logging in that then got renamed. I don't think redirecting the user to a big error view instead of an error dialog is the solution here.

I really think it is. Let's say the following happens:

1. User A shares a direct Panel page link with a colleague B.
2. Before user B can access the link, user A renames the page.
3. User B clicks the link.
   a) They are already logged in and are presented with the error view. They will know what happened and can ask their colleague if the link is broken.
   b) They are not already logged in. With this PR, they will land on the site view and be confused.

What I'm asking is: Why should case 3b) be different from case 3a) just because the user was not already logged in?

I think we have a couple problems here that add up:

• The error dialogs for redirects are bad. We should show the error view instead.
• But our error pages in the panel are also pretty bad. If I end up on a page route for a missing page, we could massively improve the experience by having a custom error view that says something like … "This page seems to have been moved or no longer exists. Go to the parent page, Go the site overview, Search for the page, etc."

Closing this as it seems to be a dead end based on the feedback